【レポート】【re:Mars 2019】M13 – #Alexa Conversations: 開発者はどのようにして自然で広がりのある会話を構築するのか #reMARS #AlexaDevs

せーのでございます。
只今私はAmazon初めてのAI・機械学習系カンファレンス「re:Mars 2019」に参加するため、アメリカはラスベガス「Aria Casino & Resort」に来ております。

このエントリーでは1日目に行われたセッション「M13: Alexa Conversations: How Developers can build natural, extensible voice conversations」をレポート致します。

スピーカーはAmazon Alexa Senior Product ManagerのJosey Sandoval氏です。

レポート

• エンジニアの人はどれくらいいる？マネージメント層は？今日はその中間の話をする
• これはビジネスサイドとエンジニアリングサイドの両方の合わさった、とても高いレベルの話だ
• Alexaの会話では私たちが行動する理由を理解することは非常に重要だ
• 対話型AIをデザインしたスキルを作るとはどういうことだろう、それを考えよう

• スキルとはAlexaの持つ機能

• 開発者視点で細かく言うと、スキルとはあなたがやりたいことをAlexaが出来るようにするための言語モデル、コード、APIの集合体であり、パッケージである
• 現在Alexaは9万のスキルがあり、その開発者は数十万に上る

• インスピレーションを与えるためにいくつかスキルを紹介する
• オンラインのスーパーマーケットのスキル
  • 視覚障害者がオンラインで注文できるようにする体験を生み出している
  • 食料品分野ではモバイルでは不十分だった技術や産業、テクノロジへのリーチが音声の技術革新によって行われている
• [beat the intro]はとても面白い
  • ゲームを音声という新しいレベルに押し上げている
  • ユーザーが何回も遊びに戻ってくるようにゲームと音声を融合した
• Droneの操作をするスキル
  • 声でドローンが離陸する
  • ロボット工学はこれから新しいユースケースとして突き抜けた存在になるだろう
  • 工場などでコントローラやアプリ、キーボードの代わりに対話が使われる

• Alexaでは2つのタイプのインタラクションが存在する。
• One Shot。タイマーを設定したり、ライトを消したり、ジャズを演奏したりする
  • 実用性があり、使いやすく、結果がすぐ出る
  • 一方、One Shotでは出来ることに制限がある
• マルチターン。ユーザーとAlexaのやり取り。
  • より複雑な目標を達成するには、例えば映画の検索などをするにはこちらが向いている
• One ShotはAlexaに沢山のエンゲージメントをもたらす
• だが現在魅力的なやり取りをするスキルはほとんどがマルチターンで作られている

• ここではSLUモデル（Spoken Language Understanding: 音声言語理解）の観点から、スキルに含まれる2つの主要な要素がどの様になっているのかを示す。それはインテントとスロットだ
• インテントは誰かが言う事に対して、近いことも含めて全てをモデル化することにあり、スロットはビジネスロジックを実行する際の変数だ
• 中規模程度のスキルでも、テキストを適切に分類するために、数千とは言わないが数百のサンプル発話が必要
• 実行時に音声がパッケージ化され、ASRに送られる。ASRは音声をテキストに変換する。
• テキストは機械で可読可能な標準のフォーマットに分類し、ビジネスロジックにペイロードされる
• あなたはビジネスロジックにてテキストとSSMLを使ってTTSエンジンにレスポンスを返す。
• TTSエンジンはテキストを音声に変換し、ユーザーに渡す。ここまでがあなたの責任に置いて行われる

• マルチターンは次にユーザーが何を言おうとしているのかを判断するのが非常に難しい
• ですのであなたは全てを用意する必要がある。運が良ければそのうち一つがユーザーの行動になる
• ダイアログのデザインや管理は非常に難しい。いくつか必要なものがある
  • 堅牢な言語モデリング。スキルの正確さはCXを上げる
  • ステートの管理。もしユーザーが「はい」と言ったらあなたはそれをどう受け止めるか
  • ビジネスロジックがAPIと結びついている必要がある。何かをいちいち許可するのはユーザーにとって面倒で苦痛
• これらを行うのは非常に複雑で難しい。最速で簡単にゴールに辿り着く方法を考えなければならない。
• その方法こそが「Alexa Conversations」だ

• まずは何が体験できるのかデモを見て欲しい。

• 素晴らしいデモだ。音声インターフェースは沢山の可変性があるので自分で構築するのは本当に難しい
• このデモの最初の方でユーザーは10:35のチケットを2枚ください、と言っている
• このユーザーがRegal Cinnebarre Palace Stationのチケットが欲しいなら、簡単に行くだろう
• しかしAlexaのエンティティ解決は3つのエンティティを示したため、Alexaはそれを引っ張ってきて次のターンに移っていく
• 素晴らしいのはAlexaがユーザーとのやり取りを使ってユーザーをゴールであるチケットの販売まで導いていることだ

• ここでポイントになるのが、ユーザーが何か別のことをした、ということだ
• ユーザーは考えを変えた。待って、この映画は何時間くらいかかるの? ユーザーは会話を別の方向に進めたがっている
• システムはそれを可能にする柔軟性を持っている

• 最後にこの会話全体のコンテキストの積み重ねの結果、ユーザーは「2枚のチケットをください」か「7時以降の回は何？」とだけ言う
• この時に「7時以降のDark Phoenixがやっている劇場」については聞かなくても良い。それは既にコンテキストの中でわかっている
• Alexaはセッションに含まれているその情報を元にレスポンスを返すことが出来る
• この機能を使えばはるかに少ない労力とコードでこの会話を可能にできる

• このような会話形AIのデザイン方法は従来のものとは異なる
• これはスキルを会話的にするだけでなく、デザインもより会話形にしたかったのであえてこうしている
• まずはSample Dialogue。注釈（annotation）をつける
  • 後述するように順番に会話を並べていく
• 次にこの会話の中からどれがエンティティに当たるかを解析する
  • これは主となるエンティティから会話を変更するかもしれない時のビジネスロジックとして価値がある
• 次にこの会話のどこにビジネスロジックのフックがあるのかを注釈として付け足す
• 最後にレスポンスとしてそれらを全て引き出し、一般的なテンプレートのマークアップとしてタグ付けする

• これは前に見せたのと同じ会話だ。マルチターンの会話をしている
• 単純に順番に会話を並べているだけだ。この順番を考える必要はない
• 重要なのはスキルに望む全ての機能のために3〜5のダイアログを考える必要がある、ということだ
• 具体的にこういうインタラクションが欲しいなら、それを加えることもできる

• 次はエンティティだ。私はアクション映画が見たいと思っている。それをgenreエンティティとしてマークアップする
• スロットと似ているが違うのは階層構造に出来るところだ
  • 映画にはジャンルがあり、時間があり、タイトルがある
  • 役者がいて、評価もあるだろう
  • それらのエンティティを定義すると、会話的にそういう状況になった時にそのエンティティを言うことができる
  • そして残りの会話でそのエンティティを使って会話をする

• 会話の中でビジネスロジックのためのフックを提供する
• 重要なのはできるだけあなたが今まで使ってきたWebやモバイルのAPIを使おうとしていることだ
• これで対話型AIをエンドユーザーとの会話に結びつけられる

• 最後にNLG(Natural Language Generation: 自然言語生成）テンプレートを定義する
• Alexaに対して、どのようにユーザーにレスポンスするかを教えるところ
• この「You may like the Dark Knight」という答えをテンプレートにする
• そのためには「You may like [MovieRecommendation]」というテンプレートを作る
• もしお勧めが2つあったら？もっと多かったら？男女の違いによってお勧めが変わったら？このテンプレートはこれらに対する柔軟性がある

• 流れ
  • ユーザーが何かを言う
  • 定義に含めたAPIがトリガーされる
  • payloadにAPIからレスポンスを返す
  • APIの応答によって複数のテンプレートを持っている。が、これは1対1ではない
  • 同じ答えにならないように、バラエティに富んだ返答をするためにテンプレートを使う

• まとめとして対話型AIの書き方はこうなる

• マークアップを覚えたくない人、エンジニア以外のためにGUIを作った
• ビルド時間は半分になった

• Alexa ConversationsのRun-timeはAlexaの会話エンジンがユーザーとの会話とAPIを取り持っている
• ここでわかるのは、会話のターンの数だけAPIがコールされているわけではない、ということ
• APIは事前に定義されたビルドの際に定義したポイントだけで呼び出される
• APIのコールはステートレスなので、実際の会話の中身を追跡する必要はない

• 違う言い方をすれは、これは時間を1ページ目に戻すようなものだ
• 今までAlexaに投資した開発者もその利点を受けられるようにする
• Alexa Conversationsは既存スキルにもAI駆動のDM(Dialogue Management)をつける
• 今までのインテントやスロットなどはそのまま使える
• ビジネスロジックにもとづいて、あるポイントでAlexa Conversationsをトリガーさせることが出来る
  • それは対話型AIをマルチターンのCX（顧客体験）から移行できるようにシグナルをレスポンスすることになる
• この体験をより多くのユーザーにしてほしい

まとめ

いかがでしたでしょうか。全体のモデルとしてはMVCモデルに似てますね。
簡単に言うとAlexa Conversationsは「今までのスキル概念からは全く違うものになる」ということがわかりました。これはスキル開発者には衝撃だったのではないでしょうか。
任せる部分はAI、つまりAmazon側に任せ、重要な部分はハンドリングする、というAmazonらしい考え方の進化だと思いました。
この進化をどう捉えるのか、是非現在のスキル開発者に聞いてみたいものです。